-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libbeat/processors/cache: new processor #36619
Conversation
b8b07d9
to
250243b
Compare
run elasticsearch-ci/docs |
8fd8793
to
42a6910
Compare
/package |
/test |
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
01583da
to
1aca826
Compare
1aca826
to
6926e84
Compare
This is the initial infrastructure for a caching metadata processor to be added. It currently only supports in-memory caching, though both planned cache types are configurable with the file cache being mocked by an in-memory cache. Additional config options are added relative to the RFC, but these are intentionally not documented at this stage.
6926e84
to
4251d26
Compare
golangci-lint appears to be ignoring the config on windows. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. Left some minor comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this file is not required (especially since the processor doesn't have any of its own fields). Are there any issues if this is removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be ok locally. Trying a full build here.
libbeat/processors/cache/cache.go
Outdated
return s, func() { | ||
// TODO: Consider making this reference counted. | ||
// Currently, what we have is essentially an | ||
// ownership model, where the put operation is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where the put operation is the owner
Or is it the first processor instantiated that is the owner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. Will fix.
libbeat/processors/cache/cache.go
Outdated
// TODO: Consider making this reference counted. | ||
// Currently, what we have is essentially an | ||
// ownership model, where the put operation is | ||
// owner. This could conceivably be problematic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the flexibility afforded to users in their beat configurations and the fact that we allow for dynamic loading/reloading of configs in some areas, I would feel more confident with a reference count.
libbeat/processors/cache/cache.go
Outdated
// ... and write it into the cloned event. | ||
result = event.Clone() | ||
if _, err = result.PutValue(dst, meta); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to clone? That is an expensive operation. I assume we want to clone so that if PutValue
fails we don't leave the event in some partially modified state. Perhaps there are some pre-checks we can perform on the event to ensure that it never fails in PutValue
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was the reason for it. I managed to significantly lower it to here, the point where the only failure possible is in the actual PutValue
operation, and though this is not documented, the implementation of that fails before a mutation, so this should be fine. I'll change it and add a defensive test for the case.
60a095d
to
a39a793
Compare
c25ce92
to
fffd521
Compare
fffd521
to
7c9f7eb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Can you please add an entry to the codeowners file for this package.
// backing data store is incomplete, and has no put operation defined, the TTL | ||
// will be invalid, but will never be accessed since all time operations outside | ||
// put refer to absolute times. setPutOptions also increases the reference count | ||
// for the memStore for all operation types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setPutOptions also increases the reference count
That extra behavior was a little surprising. Consider an explicit "retain()" method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was having similar thoughts. This is a consequence of the change to ref counting. I'm reluctant to make this two methods, but I think we get equivalent reduction in confusion by changing the name to add
and removing the comment at the call site.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole ref count code is now significantly clearer.
73bfeda
to
ac43bef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except some typos and linter issues.
}, | ||
1: { | ||
doTo: func(s *memStore) error { | ||
s.Put("one", 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s.Put("one", 1) | |
_ = s.Put("one", 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be flagged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@efd6 this rule is for the github.com/elastic/elastic-agent-libs/mapstr.M
type, right? And you have memStore
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sorry, you are correct. I've added a nolint
comment.
1: { | ||
doTo: func(s *memStore) error { | ||
s.Put("one", 1) | ||
s.Put("two", 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s.Put("two", 2) | |
_ = s.Put("two", 2) |
doTo: func(s *memStore) error { | ||
s.Put("one", 1) | ||
s.Put("two", 2) | ||
s.Put("three", 3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s.Put("three", 3) | |
_ = s.Put("three", 3) |
ddc0c59
to
27b0ce9
Compare
This is the initial infrastructure for a caching metadata processor to be added. It currently only supports in-memory caching, though both planned cache types are configurable with the file cache being mocked by an in-memory cache. Additional config options are added relative to the RFC, but these are intentionally not documented at this stage.
Proposed commit message
This is the initial infrastructure for a caching metadata processor to be added. It currently only supports in-memory caching, though both planned cache types are configurable with the file cache being mocked by an in-memory cache.
Additional config options are added relative to the RFC, but these are intentionally not documented at this stage.
This is part of the work required for elastic/integrations#2816.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs